\documentclass[a4paper,12pt]{article}
%\usepackage[none]{hyphenat}%Para que no corte las palabras que no entran en el renglon
\usepackage[framed,numbered,autolinebreaks,useliterate]{mcode}
\usepackage{graphicx}
\usepackage{float}
\usepackage[utf8]{inputenc}%para mostrar bien los acentos y esas cosas

\usepackage[spanish]{babel}%para que aparesca figura en lugar de figure
\usepackage{amsmath}%para que aparesca figura 1.1 1.2 2.3 etc y para usar las formulas



%\makeatletter
%\renewcommand\@seccntformat[1]{}%para que no aparesca el numero de la seccion en el texto
%\makeatother

\usepackage{tocloft}
\renewcommand{\cftsecleader}{\cftdotfill{\cftdotsep}}%para que el indice tenga los puntos



\begin{document}

     
      \begin{titlepage}

	  \newcommand{\HRule}{\rule{\linewidth}{0.5mm}} % Defines a new command for the horizontal lines, change thickness here
	  \center % Center everything on the page

	  %	HEADING SECTIONS
	  \textsc{\LARGE Facultad de Ingeniería}\\[0.4cm] % Name of your university/college
	  \textsc{\LARGE Universidad de Buenos Aires}\\[1.0cm] % Name of your university/college
	  \textsc{\Large Taller de programación [75.42]}\\[0.5cm] % Major heading such as course name

	  %	TITLE SECTION
	  \HRule \\[0.4cm]
	  { \Large \bfseries Editor de diagramas ER y Clases}\\[0.8cm] % Title of your document
	  { \Large \bfseries Documentación técnica}\\[0.4cm] % Title of your document
	  \HRule \\[1cm]
	  
	  %	AUTHOR SECTION
	  \begin{minipage}{0.55\textwidth}
	      \begin{flushleft} \large
		  \emph{Autores:}\\
		  Linardos Leandro (89567)\\
		  Luna Riveros Santiago (88710)\\
		  Marchese Juan Ignacio (85719)\\
		  Quinteros Aguilar Mirian (89875)\\
	      \end{flushleft}
	  \end{minipage}
	  ~%el moño hace que se separen las secciones de autor y curso
	  \begin{minipage}{0.4\textwidth}
	      \begin{flushright} \large
		  \emph{Grupo:} \\
		  No hay consenso \\
		  
		  \emph{Coordina:} \\
		  Alejandro Ferrer \\
	      \end{flushright}
	  \end{minipage}\\[1cm]

	  %	DATE SECTION
	  {\large 1er Cuatrimestre 2013}\\[1cm]

	  %	LOGO SECTION
	  \includegraphics{./Imagenes/Logo-fiuba_big.png}\\[1cm]

	  \vfill % Fill the rest of the page with whitespace

      \end{titlepage}
      
      
%-------------------------------------------------------------------------------------------------------------
     \tableofcontents
     \setcounter{tocdepth}{2}
     \newpage
      
      
%-------------------------------------------------------------------------------------------------------------      
    \section{Requerimientos de software}
	La aplicación fue desarrollada para correr en distribuciones basadas en GNU/Linux. Para instalar el programa se debe contar con las librerias gtkmm-2.4 y libxml-2.6. o versiones posteriores. Además se debe contar con el programa make y el compilador g++ (utilizado por el anterior), para compilar la aplicación.
%-------------------------------------------------------------------------------------------------------------      
    \section{Descripción general}
	  
	El proyecto tiene como resultante un aplicativo con interfaz gráfica que permite crear y editar diagramas Entidad-Relación y diagramas de clases, esto a través de la utilización del mouse y teclado. Además existe la posibilidad de tomar un diagrama de Entidad-Relación y convertirlo de forma automática a uno de clases.

	Se utilizó el estándar UML2 para la simbología de los diagramas de clases.
%-------------------------------------------------------------------------------------------------------------      
    \section{Patrones implementados}
      
	Dentro de los principales patrones implementados se encuentran:

	\subsection{Arquitectura MVC}
	    Divide la aplicación interactiva en tres áreas: procesamiento, salida y entrada.

	    Las abstracciones utilizadas son:

	    \begin{itemize}
		\item Modelo(Model): Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada.

		\item Vista(View): Muestra la información al usuario. Cada vista tiene asociado un componente controlador.

		\item Controlador(Controller): Reciben las entradas, usualmente como eventos que codifican los movimientos o pulsación de botones del ratón, uso del teclado, etc. Los eventos son traducidos a solicitudes para el modelo o la vista.
	    \end{itemize}

	\subsection{Composite}
	    El patrón Composite nos sirve para construir objetos complejos a partir de otros más simples y similares entre sí, gracias a la composición recursiva y a una estructura en forma de árbol. Esto simplifica el tratamiento de los objetos creados, ya que al poseer todos ellos una interfaz común, se tratan todos de la misma manera.


	\subsection{Strategy}

	    El área de dibujo posee un handler, que encapsula el comportamiento ante los eventos; determinando como se debe realizar el intercambio de mensajes entre diferentes objetos para resolver la respuesta al evento. El patrón estrategia permite mantener un conjunto de algoritmos, de entre los cuales el área de dibujo puede elegir aquel que le conviene, e intercambiarlo dinámicamente según sus necesidades.

	\subsection{Bridge}

	    Como el programa soporta dos tipos de diagramas, se tendrán una estructura repetida, un Workspace que contendrá un diagrama, y este último contendrá elementos. Se decidió utilizar el patrón bridge para desacoplar la interfaz general de cada implementación en particular y de esta manera reducir la cantidad de código duplicado.
\newpage
%-------------------------------------------------------------------------------------------------------------      
    \section{Módulos}

	\subsection{Capa de interfaz gráfica}

	    La interfaz gráfica cuenta de una ventana principal que se compone básicamente de:
	    \begin{itemize}
		\item Una secuencia de tabs con un área de dibujo cada uno, donde se van agregando los componentes del diagrama para su visualización y edición.
		\item Una barra de herramientas con los distintos componentes (tanto para diagramas ER como de clases).
		\item Una barra de menú con las diversas acciones como abrir proyecto, guardar, imprimir, etc. 
	    \end{itemize}

	    Los manejadores de eventos (handlers) son los encargados de comunicar y gestionar la ocurrencia de cada evento en particular.


	    \subsubsection{Tabs}
		La clase tabs representa un conjunto de subventanas que pertenecen al proyecto actual. Tiene un objeto de la clase BarraDeMenu que se explica más abajo.

	    \subsubsection{DrawingAreaPlusPlus}
		Clase que encapsula el widget Drawing Area de gtk y le agrega la funcionalidad necesaria para dibujar componentes visuales relativos al diagrama. En todo momento, contiene un handler que abstrae el comportamiento que debe realizarse de acuerdo a la sucesión de eventos ocurridos durante la interacción con el usuario. Se encarga de recibir todos los eventos y los redirecciona al handler actual, como por ejemplo el click derecho o izquierdo del mouse. Contiene una lista de VisualCompositeComponents que recorre para dibujar cada vez que se le avisa de alguna modificación en los mismos mediante el método reDraw.

		Ofrece el método getTouchedVisualComponents para obtener el componente visual correspondiente a una posición dada. Para ello, utiliza una serie de cálculos, donde verifica la intersección con las áreas de influencia de los componentes. Además dibuja un área de selección y líneas correspondientes a conexiones en proceso de creación, seteando los atributos correspondientes.
		La figura 4.1 muestra un diagrama de clases indicando como se relaciona esta clase con otras.

	    \begin{figure}[H]
		    \centering
		    \numberwithin{figure}{section}
		    \includegraphics[width=1.0\textwidth]{./Imagenes/ClassDesignModel.png}
		    \caption{Diagrama DrawingAreaPlusPlus}
	    \end{figure}
		
	    \subsubsection{Workspace}
		Se llama Workspace al conjunto de barra de herramientas, tabs, áreas de dibujo y barra de menú que permite la construcción y/o edición de un tipo de diagrama. Esta clase hereda de DrawingAreaPlusPlus agregándole la funcionalidad adicional requerida para la interfaz del diagrama. Provee los métodos para imprimir, guardar y levantar los diagramas,  Es decir, si se elige crear un diagrama de clases, todos los componentes de la interfaz visual contienen las funcionalidades referentes a los diagramas de clases.

		Para implementar los tipos de workspace se especializó la clase Workspace en WorkspaceDER y WorkspaceClasses.
\newpage
	    \subsubsection{BarraDeHerramientas}
		Clase que contiene los botones de los componentes del diagrama, los cuales al ser presionados establecen un HandlerCreateComponent en el DrawingArea. Dicho handler, se encarga de crear el componente elegido, según el botón que se haya presionado y utilizando una función template.


	    \subsubsection{BarraDeHerramientasContainer}
		Esta clase contiene una instancia de una Barra de Herramientas para los diagramas ER y otra barra de herramientas para los diagramas de clases. La contiene la VentanaPrincipal para que pueda hacer el intercambio de tipo de barra de herramientas según el proyecto actual

	    \subsubsection{BarraDeMenu}
		Contiene el grupo de acciones y de botones asociados a ellas. Redirecciona un grupo de estas acciones al Workspace, tales como imprimir, abrir, guardar, exportar, etc. Otras acciones como borrar, entre otras, son redireccionadas al handler actual en el Workspace.

	    \begin{figure}[H]
		    \centering
		    \numberwithin{figure}{section}
		    \includegraphics[width=1.0\textwidth]{./Imagenes/ClasesGeneral.png}
		    \caption{Estructura general de la interfaz gráfica.}
	    \end{figure}
\newpage

      

	\subsection{Componentes visuales}

	    \subsubsection{VisualComponent}

		Es una interfaz que deben cumplir los distintos componentes para poder ser dibujados y manejados por el DrawingArea. Por ejemplo, define métodos como:

		\begin{itemize}
		    \item on\_expose y draw: para dibujar el componente de acuerdo a su estado actual, por ejemplo seleccionado o no.
		    \item getInfluenceArea y otras funciones relativas a las proporciones y posiciones de los componentes visuales: para permitir la lógica de intersecciones entre componentes (por ejemplo, cuando una línea es dejada sobre un componente) y eventos del mouse.
		    \item on\_move: para cambiar la posición del componente visual.
		\end{itemize}

	    \subsubsection{VisualCompositeComponent}

		Hereda de VisualComponent y agrega la funcionalidad especializada en componentes compuestos del diagrama. Posee una colección de otros elementos visuales, tales como los conectores en un elemento o los segmentos en una línea. Además de implementar algunos métodos del padre, agrega métodos más específicos como serializar y mostrar propiedades. 

		Especificaciones de esta clase para el diagrama ER:

		\begin{itemize}
		    \item VisualComponentEntity
		    \item VisualComponentForkVia
		    \item VisualComponentRelation
		    \item VisualComponentAttribute
		    \item VisualComponentCompositeAttribute
		    \item VisualComponentVia
		\end{itemize}

		Especificaciones de esta clase para el diagrama de clases:
		\begin{itemize}
		    \item VisualClassComponentVia
		    \item VisualClassComponentClaseAbstracta
		    \item VisualClassComponentClase
		\end{itemize}


		Básicamente, los componentes visuales difieren en la forma en que se dibujan y en el área de influencia. Además, como es de esperar, se diferencian en el componente lógico del modelo que encapsulan. En algunos casos agregan un comportamiento distinto, como en el VisualComponentVia. La visual correspondiente a la via posee segmentos (que también son componentes visuales), a diferencia de los demás que poseen conectores. Tiene métodos que permiten el trazado automático de las líneas ortogonalmente, así como la unión de dos segmentos cuando existe un tercero entre medio de escasa longitud. 
		Existen otros componentes visuales que componen a los VisualCompositeComponent antes mencionados:

		\begin{itemize}
		    \item VisualComponentConnector: la funcionalidad mas importante del VisualComponentConnector es permitir la conexión entre un componente y una via y transmitir los eventos entre los mismos, tales como el movimiento.
		    \item VisualComponentSegment: encapsula los datos necesarios para el trazado automático de las vias, tales como longitud, si es vertical y si es movible. Estos últimos datos se utilizan para diferenciar entre los casos en que una via debe seguir al componente al que esta conectado y el caso en que ambos componentes de la via se muevan al mismo tiempo en cuyo caso las vias no se deben extender, sino moverse manteniendo su forma.
		\end{itemize}

		\begin{figure}[H]
			\centering
			\numberwithin{figure}{section}
			\includegraphics[width=1.2\textwidth, angle =90 ]{./Imagenes/Visual.png}
			\caption{Diagrama de los componentes visuales}
		\end{figure}
		\clearpage
      
		\subsubsection{Ventanas}

		    Ventana Principal:
		    Esta ventana no es mas que un contenedor de la barra de herramientas, la barra de menú y los tabs. Estos últimos corresponden a los diferentes workspaces de trabajo. Es decir que permiten la edición de varios diagramas a la vez. Posee métodos que permiten crear, guardar, abrir y cambiar nombre al diagrama del tab actual, así como agregar nuevos tabs.


		\subsubsection{Handlers}
		    Los manejadores de eventos (handlers) encapsulan el estado de lo acontecido recientemente y, en base a ello, definen el comportamiento frente a un evento. Por ejemplo, si se recibe el evento de on\_release\_left\_click, el HandlerConnectComponent intentara buscar un conector para crear la via y conectar los dos componentes, mientras que el HandlerSelected en el caso de estar moviendo un componente lo dejará en la posición correspondiente al evento. Estos handlers heredan de la clase Handler, que define la interfaz necesaria para recibir los mensajes de los eventos que envía el Workspace, la barra de herramientas y los tabs. A continuación se listan los diferentes handlers y una breve explicación de sus comportamientos.

		\begin{itemize}
		    \item HandlerDefault: es el encargado de decidir cual es el próximo handler que pasará a recibir los eventos, según el evento que recibe.
		    \item HandlerCreateComponent: recibe como parámetro un componente visual creado por el botón correspondiente en la barra de herramientas. Mueve el componente hasta la posición donde se lo suelta y agrega el mismo a la colección de la DrawingArea y al diagrama en cuestión.
		    \item HandlerCreateSelection: este handler es habilitado por el handlerDefault cuando se hace click en una posición donde no se encuentra ningún componente, con el fin de que cuando reciba la señal de release del click izquierdo crear una colección con todos los componentes que quedaron encerrados en el cuadro de selección. Este último, se va dibujando mientras se recibe la señal on\_motion\_notify.
		    \item HandlerSelected: recibe una colección de componentes visuales seleccionados y de acuerdo a los eventos posteriores decide que acción aplicar sobre la misma. Por ejemplo: si se hace click derecho se muestra un menú desplegable, donde se pueden elegir acciones como copiar, cortar, borrar y propiedades.
		    \item HandlerConnectComponent: al hacer click sobre un conector, se habilita este handler, que se encarga de dibujar una línea hasta el punto donde se suelta el click, verificando en esa posición si existe otro conector, para lograr una conexión exitosa y crear la via, agregándola al diagrama y a la colección de componentes visuales en el DrawingArea.
		    \item HandlerEditSegment: se habilita este handler haciendo click sobre un segmento y permite arrastrar el mismo, modificando los segmentos adyacentes cuando es necesario.
		\end{itemize}

		\subsection{Capa de xml}

		    En esta capa encontramos las clases necesarias para levantar y persistir los diagramas en archivos XML. Los diagramas y sus funcionalidades seran almacenados en dos XML.

		    Uno de los xml corresponde a los atributos propios de la representación gráfica: posición en la pantalla, etc.
		    El otro xml guarda los atributos de la entidad, como el nombre, tipo, atributos, etc.

		    Esta estrategia se utiliza para todos los diagramas, ya sea de clases o de ER. La forma de distinguir qué determinados XMLs corresponden a un tipo de diagrama u otro se guarda en el mismo archivo XML. Se verá en detalle en el ejemplo de XML más adelante.

		    Las clases involucradas en la persistencia XML son:

		\begin{itemize} 
		    \item XMLWriter: clase que posee los métodos más usuales como agregar nodos o propiedades y guardar el archivo.

		    \item XMLReader: clase que posee los métodos más usuales como obtener nodo, propiedades o contenido de nodo, siguiente nodo, y comprobaciones para asegurar la existencia de nodo hijo.
		\end{itemize}

		    Las opciones de guardar o abrir un diagrama persistido en XML se acceden desde la barra de menú. 

		    A continuación se muestra un ejemplo de XML para un diagrama ER. Notar el atributo 'type' en la etiqueta 'diagram' que en este caso corresponde a un número que representa que es un diagrama ER.

		    \newpage
		    \lstset{language=XML}
		    \begin{lstlisting}
<?xml version="1.0" encoding="UTF-8"?>
<diagram name="test1" type="2" sizex="454" sizey="343">
    <atributo name="atributo0" x="406" y="200" id="0"/>
    <atributo name="atributo1" x="613" y="196" id="1"/>
    <entidad name="entidad" x="500" y="315" id="2"/>
    <Via name="Via" x="411" y="205" nroSalida="0" id="3">
	    <Punto x="414" y="208" movible="0"/>
	    <Punto x="521" y="318" movible="0"/>
    </Via>
    <Via name="Via" x="618" y="201" nroSalida="0" id="4">
	    <Punto x="621" y="204" movible="0"/>
	    <Punto x="545" y="318" movible="0"/>
    </Via>
    <at_compuesto name="at_compuesto" x="707" y="315" id="5"/>
    <relacion name="relacion" x="493" y="418" id="6"/>
    <entidad name="entidad" x="492" y="513" id="7"/>
    <Via name="Via" x="523" y="511" nroSalida="0" id="8">
	    <Punto x="537" y="516" movible="0"/>
	    <Punto x="529" y="516" movible="1"/>
	    <Punto x="529" y="445" movible="1"/>
	    <Punto x="533" y="445" movible="0"/>
    </Via>
    <Via name="Via" x="542" y="424" nroSalida="0" id="9">
	    <Punto x="545" y="427" movible="0"/>
	    <Punto x="538" y="427" movible="1"/>
	    <Punto x="538" y="342" movible="1"/>
	    <Punto x="540" y="342" movible="0"/>
    </Via>
    <Via name="Via" x="708" y="337" nroSalida="0" id="10">
	    <Punto x="711" y="340" movible="0"/>
	    <Punto x="559" y="342" movible="0"/>
    </Via>
    </diagram>
		    \end{lstlisting}

		Para guardar el subdiagrama, se agrega el siguiente nodo a cada elemento que contiene dicho subdiagrama:
		\newpage
		\lstset{language=XML}
		    \begin{lstlisting}
<other_diagram name="NombreDiagramaDestino" id="IdElementoEnDestino"/>.
		    \end{lstlisting}

		El mismo representa el nombre del diagrama en el que se incluyó el subdiagrama hijo y el identificador del elemento en dicho subdiagrama (representado por la posición del mismo en dicho diagrama).

		
		Para los diagramas de clases (el primero corresponde a la representación y el segundo a los datos del componente):

		\lstset{language=XML}
		    \begin{lstlisting}
<?xml version="1.0" encoding="UTF-8"?>
<diagram name="bbbg" type="1" sizex="884" sizey="459">
  <class name="clase B" type="7" x="354" y="452" id="0"></class>
  <class name="clase A" type="7" x="383" y="124" id="1"></class>
  <class name="clase C" type="7" x="712" y="215" id="2"></class>	
  <via name="" type="10" x="156" y="292" nroSalida="0" relationType="2" id="3" idStart="0">
	<Punto x="417" y="455" movible="0"></Punto><Punto x="272" y="455" movible="1"></Punto>
	<Punto x="272" y="191" movible="1"></Punto><Punto x="386" y="191" movible="0"></Punto>
  </via>
  <via name="" type="10" x="720" y="359" nroSalida="0" relationType="4" id="4" idStart="2">
	<Punto x="715" y="258" movible="0"></Punto><Punto x="541" y="258" movible="1"></Punto>
	<Punto x="541" y="438" movible="1"></Punto><Punto x="405" y="438" movible="0"></Punto>
  </via>
  <class name="clase D" type="7" x="818" y="493" id="5"></class>
  <via name="" type="10" x="875" y="494" nroSalida="0" relationType="5" id="6" idStart="5">
	<Punto x="878" y="497" movible="0"></Punto><Punto x="796" y="497" movible="1"></Punto>
	<Punto x="796" y="270" movible="1"></Punto><Punto x="716" y="270" movible="0"></Punto>
</via>
</diagram>
		    \end{lstlisting}

		    \newpage
		\lstset{language=XML}
		    \begin{lstlisting}
<?xml version="1.0" encoding="UTF-8"?>
<diagram name="bbbg">
	<class name="clase B" classtype="0" id="0">
	<attribute name="atributo_1" atName="atributo_1" dataType="void" static="false" visibility="-">
	</attribute>
	<attribute name="atributo_2" atName="atributo_2" dataType="void" static="false" visibility="-">
	</attribute>
	<method name="metodo_1" methodName="metodo_1" returns="void" visibility="+">
		<parameter name="parametro_1" tipoDato="void" valor=""></parameter>
	</method>
	</class>
	<class name="clase A" classtype="2" id="1">
		<method name="metodo_1" methodName="metodo_1" returns="void" visibility="-">
			<parameter name="parametro_1" tipoDato="void" valor=""></parameter>
		</method>
		<method name="metodo_2" methodName="metodo_2" returns="void" visibility="+">
		</method>
	</class>
	<class name="clase C" classtype="0" id="2">
	<attribute name="atributo_1" atName="atributo_1" dataType="void" static="false" visibility="-">
	</attribute>
	<attribute name="atributo_2" atName="atributo_2" dataType="void" static="false" visibility="#">
	</attribute>
	<method name="metodo_1" methodName="metodo_1" returns="void" visibility="#">
		<parameter name="parametro_1" tipoDato="void" valor=""></parameter>
		<parameter name="parametro_2" tipoDato="void" valor=""></parameter>
	</method>
	<method name="metodo_2" methodName="metodo_2" returns="void" visibility="+"></method>
	</class>
	<class name="clase D" classtype="0" id="5">
	<attribute name="atributo_1" atName="atributo_1" dataType="void" static="false" visibility="-">
	</attribute>
	<attribute name="atributo_2" atName="atributo_2" dataType="void" static="false" visibility="-">
	</attribute>
	<method name="metodo_1" methodName="metodo_1" returns="void" visibility="+"></method>
	<method name="metodo_2" methodName="metodo_2" returns="void" visibility="+"></method>
	</class>
</diagram>
		    \end{lstlisting}

		    Resultado:

		\begin{figure}[H]
		    \centering
		    \numberwithin{figure}{section}
		    \includegraphics[width=1.0\textwidth]{./Imagenes/diagramaxml.png}
		    \caption{Resultado del diagrama de clases XML.}
	    	\end{figure}

\newpage

		\subsection{Modelo}

		    \subsubsection{Diagrama}

			Clase básica del modelo lógico de la aplicación. Se encarga de contener todos los componentes del diagrama y permitir su edición.

		    \subsubsection{Componente}
			Clase que establece la interfaz de todos los elementos que puede contener un diagrama. Los conectores se encargan de mantener correctamente conectada una línea a sus componentes. Los componentes disponibles son para el diagrama ER son:

		    \begin{itemize}
			\item Attribute
			\item Entity
			\item Relation
			\item Connector
			\item Segment
			\item Fork
			\item Via
		    \end{itemize}

		    Los componentes disponibles son para el diagrama de clases son:

		    \begin{itemize}
			\item Atributo
			\item Clase
			\item ClaseAbstracta
			\item ClaseConcreta
			\item Interfaz
			\item Metodo
			\item Parametro
			\item TipoDato
			\item ViaClasses
		    \end{itemize}

		    \begin{figure}[H]
			    \centering
			    \numberwithin{figure}{section}
			    \includegraphics[width=1.2\textwidth, angle =90]{./Imagenes/Componentes.png}
			    \caption{Diagrama de clases de los componentes}
		    \end{figure}
		    \clearpage

		\subsection{Conversión}

			El módulo de conversión se encarga de generar un diagrama de clases a partir de un diagrama ER. Para esto, se definieron reglas de conversión para los componentes del diagrama ER:

			\begin{itemize}
			\item Entidad: Cada entidad en el modelo de datos se mapea en una clase en el modelo de clases. El nombre de la clase es el nombre de la entidad. Notar que se pierde información sobre la/s clave/s de la entidad.
			\item Atributo de entidad: Un atributo simple de una entidad se mapea a un atributo de la clase correspondiente a esa entidad. Un atributo compuesto de una entidad se mapea a una clase con sus componentes como atributos. Se crea una relación de uso, la clase que representa al atributo compuesto es usada por la que tiene el atributo compuesto.
			\item Relación con atributos: Una relación con atributos se mapea como si se tratara de una entidad, es decir, se mapea a una Clase y sus atributos como atributos de clase. 
			\item Relación ternaria: Una relación ternaria se mapea a una clase. Se mantienen las cardinalidades en relaciones de tipo asociación bi-navegables.
			\item Relación sin atributos: Una relación sin atributos no se mapea, se mapean las vías que unen las dos entidades a la relación.
			\item Fork: Se mapea como una generalización (herencia).
		    \end{itemize}

		    Para realizar la conversión se crea una instancia de ConversorDERaClases indicando el workspace DER a convertir y un delegado que implemente la interfaz ConversorDERaClasesDelegate. Enviando el mensaje convertir() a una instancia de ConversorDERaClases comienza el proceso de conversión. Al finalizar, el delegado recibe el mensaje conversorDERaClasesTerminoConversion(WorkspaceClases *) junto al nuevo workspace de clases producto de la conversión.

		    Es importante remarcar que el proceso de conversión se realiza en dos pasadas. En la primera pasada se convierte todo lo que genere clases según las reglas expuestas anteriormente y también atributos simples de entidades. En la segunda pasada, los componentes de clases antes creados se unen mediante vias en base a la conexiones entre componentes ER convertido. La conversión en dos pasadas fue la solución elegida ante el potencial problema de necesitar un componente del modelo de clases (generalmente una clase) que no haya sido creada debido a que aún no se haya procesado el componente ER que le da origen.



%-------------------------------------------------------------------------------------------------------------            
      
    \section{Usabilidad}

	El objetivo principal del trabajo fue lograr una aplicación que sea fácil de utilizar. Se buscó que generar un diagrama sea una tarea fácil e intuitiva con las herramientas de la aplicación, similares a otras que utilizamos en la vida cotidiana en otro tipo de aplicaciones. Es por ello que hizo hincapié en el manejo de eventos y el Drag \& Drop. Partiendo de la idea de que la utilización del mouse para crear elementos y arrastrarlos era clave a la hora de lograr una aplicación de fácil uso, para cualquier tipo de usuario, no necesariamente un usuario experto. En un primer momento, se analizaron otras aplicaciones (Enterprise Architect, Astah, Dia, Yed), buscando todos los puntos a favor que tenían. Esos mismos puntos fueron los objetivos a alcanzar de esta aplicación.

          

\end{document}
